Despite the vast improvement in the overall performance and reliability of storage devices (e.g., disk drives or flash memory drive), it is imperative that enterprises have disaster recovery systems and procedures in place. To that end, many enterprises are relying on the backup capabilities of network-based disk arrays (e.g., network-attached storage (NAS) and storage area network (SAN) systems), referred to herein simply as network-based storage systems. One feature of network-based storage systems that is particularly useful to enterprises is a type of backup procedure commonly referred to as a snapshot—a copy of a set of files, directories or data blocks as they were at a particular point in the time.
Many server applications, such as Oracle® database, and Microsoft® Exchange and SQL Server, are able to utilize snapshots as a mechanism for backing up data. A typical backup procedure for one of these server applications involves two distinct phases—a backup phase and a verification phase. Referring to FIG. 1, the backup phase involves generating the actual snapshot from an existing volume at the network-based storage system 10. For instance, a server application 12 executing on the host system 14 requests that a backup (e.g., snapshot) be generated for a particular database, for example, “F:\databases\db—1.” In this case, “db—1” is the name of a database located on the volume and disk assigned to drive letter “F:\” and in the directory “databases”. When drive letter “F:\” is mapped to a Logical Unit Number (LUN) of a network-based storage system 10, a storage management application 16 executing on the host system 14 initiates a snapshot operation by communicating one or more commands or instructions to the storage system 10, directing the storage system 10 to initiate the snapshot operation and generate the snapshot at the storage system 10.
After the snapshot has been generated, the host-based server application 12 performs a verification process to ensure that the snapshot operation captured the proper data and that no data corruption has occurred. However, in order for the server application 12 executing at the host system 14 to read and verify the snapshot data, the mount (and unmount) logic 18 of the host system 14 must first mount the snapshot to the host system 14. Because a snapshot may be associated with multiple LUNs, the verification process may require that the host system 14 consecutively mount one LUN after another until each LUN of the snapshot has been mounted, verified, and unmounted.
Mounting a LUN of a snapshot to the host system 14 requires that the storage management application 16 at the host system 14 perform a discovery operation to map the host-based snapshot reference (e.g., H:\snapshots\sn—1) to a storage system-based reference (e.g., a LUN path) corresponding to a LUN of the snapshot. For example, the discovery operation generally requires that the dynamic mapping logic 20 of the mount logic 18 on the host system 14 identify the various resources available and in-use at both the host system 14 and the storage system 10. For example, during the discovery operation, dynamic mapping logic 20 of the host system 14 performs volume and disk enumeration procedures to analyze volume and disk objects at the host system 14 for the purpose of identifying the various volumes and disks “known” to the host system, and the alphabetical identifiers (e.g., drive letter assignments, such as, “C:\” or “D:\”) and/or volume mount points and their corresponding physical or logical drives, partitions or LUNs (Logical Unit Numbers). The information resulting from the volume and disk enumeration operations is filtered to identify the specific mappings between host-based references and any LUN information of the storage system 10 that corresponds with the snapshot that is to be mounted to the host system 14. Once the discovery operation has completed, the storage management application 16 will mount a LUN of the snapshot that is being verified by generating a mapping of a host-based reference (e.g., a drive letter assignment or volume mount point) to the LUN information (e.g., LUN path) identifying the location of the snapshot on the storage system.
Once a LUN of the snapshot has been mounted to the host system 14, the server application 12 reads and analyzes the snapshot data associated with that specific LUN to verify that the data have not been corrupted and the data represent a viable backup. When the verification process is completed, the LUN of the snapshot is unmounted from the host system 14. If there are other LUNs associated with the snapshot, the above-described process is repeated until each LUN of the snapshot has been mounted, verified and unmounted. If the server application 12 at the host system 14 has multiple snapshots to verify—as is often the case with Oracle® database, Microsoft® Exchange and SQL Server, where each snapshot may represent a backup of a particular database—the server application 12 must go through the mounting and unmounting procedure for each LUN of each snapshot to be verified. Unfortunately, for each mount request received, the discovery process described above must be performed so that a LUN can be dynamically mapped to a host-based resource at the time the mount request is received and processed. Consequently, the time consuming discovery operation must be repeated each time a LUN of a snapshot is to be mounted. This causes an undesirable delay in the verification of a set of snapshots, due to the time it takes to mount the LUNs corresponding with a snapshot.